home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 378 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  2.5 KB
  1. Path: engnews1.Eng.Sun.COM!taumet!clamage
  2. From: Max TenEyck Woodbury <mtew@cds.duke.edu>
  3. Newsgroups: comp.std.c++
  4. Subject: Re: Time representations
  5. Date: 19 Feb 1996 23:16:36 GMT
  6. Organization: ?
  7. Approved: clamage@eng.sun.com (comp.std.c++)
  8. Message-ID: <4gb0ck$538@engnews1.Eng.Sun.COM>
  9. NNTP-Posting-Host: taumet.eng.sun.com
  10. Mime-Version: 1.0
  11. Content-Type: text/plain; charset="us-ascii"
  12. Content-Transfer-Encoding: 7bit
  13. X-Nntp-Posting-Host: dukcds.cds.duke.edu
  14. Cc: mtew@cds.duke.edu
  15. X-Lines: 53
  16. Content-Length: 1751
  17. Originator: clamage@taumet
  18.  
  19. Bill Spitzak wrote:
  20. > 
  21. >...
  22. > 
  23. > Who says that other culture uses things called "months" or "seconds"
  24. > or "hours", etc.
  25. >    I am not an expert on this, but from what little I know the divisions
  26. of a day into "hours" and "minutes" seems to be fairly uniform across
  27. cultures.  The scientific comunity seems to have a uniform definition of
  28. second as well.  "Months" are more problimatic but many cultures have a
  29. time unit of roughly the length of the lunar cycle.  The Gregorian calandar
  30. seems to be the worst approximation in that regard.  If you had asked about
  31. "weeks" however, I'd be pretty much lost.
  32. > 
  33. > Perhaps the structure should have been called
  34. > "eurocentric_white_opressor_time_t" to more correctly reflect it's
  35. > purpose?
  36. > 
  37.  
  38.     Only if you REALY insist, but I'd still object :-).  "moderately_general_
  39. time_conversion_t" was what I was trying for.
  40.  
  41. > Seriously, these attempts at PC-correctness I think are insluting to
  42. > the societies involved.  Are they too stupid or primitive to cram
  43. > another value in the field, or to make up their own structure, without
  44. > our benevolent guidance?
  45. > 
  46.  
  47.     This is SUPPOSED to be an INTERNATIONAL standard and the current phrasing
  48. REQUIRES certain interpretations of these fields.  An acknowledgement that 
  49. locales other then "C" can redefine the precise meaining of some of the fields 
  50. would allow broader application without having to get exemptions for what is 
  51. obviously the "correct thing to do".
  52.  
  53.     The problem is not, as you imply, that people are stupid or primitive, but
  54. that standards, by their nature, are narrow minded and literal.  As currently
  55. phrased, reinterpreting these fields is not allowed no matter what local is
  56. in control of time.  Now THAT is insulting.  
  57.  
  58.  
  59.         Max
  60.  
  61. [ To submit articles: Try just posting with your newsreader.  If that fails,
  62.               use mailto:std-c++@ncar.ucar.edu
  63.   FAQ:    http://reality.sgi.com/employees/austern_mti/std-c++/faq.html
  64.   Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
  65.   Comments? mailto:std-c++-request@ncar.ucar.edu
  66. ]
  67.